Many electronic devices include both a primary and a secondary processor. The primary processor is typically used to perform core functions of the electronic device. The secondary processor performs other functions, such as media processing, math coprocessing, and other specialized functions, freeing the primary processor from such processing tasks. Typically, the functions are performed in real time by both processors to increase the overall processing speed of the electronic device. To further relieve the primary processor, it is preferable that the secondary processor perform its functions with little control by the primary processor. Thus, it is preferable for the secondary processor to load programs and data and to execute such programs independently of the primary processor. Enabling such capabilities requires a secondary processor control program to manage input/output (I/O) tasks, communication with the primary processor, and other overhead. This control program is sometimes referred to as an execution kernel.
Effectively, the execution kernel is a secondary operating system specifically for the secondary processor. Since the secondary processor is frequently a DSP that is used for real time functions, the execution kernel is often referred to as “a DSP execution kernel” or “a real time DSP operating system.” A number of such real time DSP operating systems are currently available for general purpose DSPs, including the Visible Caching Operating System (VCOS™) by AT&T Corp., SPOX™, which was originally developed by Spectron Microsystems, Inc. (later acquired by Texas Instruments, Inc.), and MWAVE™ by International Business Machines, Inc.
The above-identified real time DSP operating systems are generally multitasking operating systems with some interrupt and memory management capabilities. However, such capabilities are achieved at the expense of throughput speed, because interrupt and memory management tasks are relatively high overhead tasks. These capabilities and their corresponding overhead accommodate branching and other non-sequential instructions and are often included in application programs, designed for and executed by the DSP under the control of the real time DSP operating system. As with any programming language, such non-sequential instructions provide DSP application program developers with flexibility and high level programming capability. Requiring developers to employ only sequential programs could reduce or eliminate at least some of the corresponding overhead. However, use of only sequential programs would limit the desired flexibility, are difficult to write, and would not necessarily avoid the need for memory management overhead. To reduce overhead without sacrificing flexibility, many techniques used by conventional compilers and assemblers may be adopted or adapted for DSPs. Compiled or assembled DSP application programs can interface with the real time DSP operating system so as to reduce overhead tasks. However, compilers and assemblers have not eliminated the interrupt handling, memory management, and other overhead that must be performed by a real time DSP operating system.
To improve processing efficiency of a secondary processor such as a DSP, it would be preferable to minimize or eliminate the need for overhead processing functions in the secondary processor's real time operating system, without sacrificing functionality of application programs, without overburdening the application programmer, and without pushing overhead processing up to the primary processor. For example, it would be desirable to minimize or eliminate the need for interrupt handling, without sacrificing an ability to modify DSP application program values during run time. Similarly, it would be desirable to minimize or eliminate memory management functions, without requiring the DSP application programmer to predefine a memory map, and without pushing the memory management functions up to the primary processor.
Conventional compiler, assembler, and linking techniques are inadequate to achieve these desirable capabilities, because they assume that many interrupt handling, memory management, and other overhead processing functions are available through the real time operating system. However, the overhead processing functions cannot be eliminated from the real time operating system without pushing these functions back to the primary processor, to the compiler, to the assembler, to the linker, or to the programmer. It is clearly undesirable to impose a great deal of rigid design requirements on the programmer. Thus, no single aspect can be changed to achieve the desired efficiencies. Instead, a hybrid of minimal programming guidelines, automatic compile time memory mapping, and a minimal DSP execution kernel is warranted.